Conversation
|
I'm experimenting with building the package locally on Linux to begin with - will post any feedback after some experimentation. |
|
Something odd about the build on macOS AArch64 - a snippet of the output: I'll have to check whether the package builds on |
|
The package built OK on |
|
The error seems to be coming from the ThreadSanitizer build, which should be supported even in 14 on macOS AArch64: https://releases.llvm.org/14.0.0/tools/clang/docs/ThreadSanitizer.html |
|
I found a hardcoded |
|
The following (or something a little more elegant) also needs to be applied because it influences the build of diff --git a/conda-recipes/llvmdev/build.sh b/conda-recipes/llvmdev/build.sh
index ef21f54..6a5558d 100644
--- a/conda-recipes/llvmdev/build.sh
+++ b/conda-recipes/llvmdev/build.sh
@@ -10,8 +10,10 @@ LLVM_TARGETS_TO_BUILD=${LLVM_TARGETS_TO_BUILD:-"all"}
# This is the clang compiler prefix
if [[ $build_platform == osx-arm64 ]]; then
DARWIN_TARGET=arm64-apple-darwin20.0.0
+ DARWIN_ARCH=arm64
else
DARWIN_TARGET=x86_64-apple-darwin13.4.0
+ DARWIN_ARCH=x86_64
fi
mv llvm-*.src llvm
@@ -74,7 +76,7 @@ if [[ $(uname) == Darwin ]]; then
# Once we are using our libc++ (not until llvm_build_final), it will be single-arch only and not setting
# this causes link failures building the santizers since they respect DARWIN_osx_ARCHS. We may as well
# save some compilation time by setting this for all of our llvm builds.
- _cmake_config+=(-DDARWIN_osx_ARCHS=x86_64)
+ _cmake_config+=(-DDARWIN_osx_ARCHS=${DARWIN_ARCH})
elif [[ $(uname) == Linux ]]; then
_cmake_config+=(-DLLVM_USE_INTEL_JITEVENTS=ON)
# _cmake_config+=(-DLLVM_BINUTILS_INCDIR=${PREFIX}/lib/gcc/${cpu_arch}-${vendor}-linux-gnu/${compiler_ver}/plugin/include) |
|
Got this error on my macos (M1), looking |
|
Skipping those binaries for now: |
|
Validated in macOS & Linux |
|
Windows: |
|
Validated |
|
Added a patch for macOS build in latest commit to expose builtin symbols |
gmarkall
left a comment
There was a problem hiding this comment.
I think this is looking good and all outstanding issues are resolved.
We should note (in any announcements following the merge) that we're not building all of compiler-rt, but this is just building the compiler-rt builtins.
This enables the build of compiler-rt builtins with the following changes: - Add `compiler-rt` to the list of LLVM projects to build - Disable the build of all `compiler-rt` components except for the builtins. Whilst it would be interesting to add these, they seem to require clang to be built at the same time. - Setting the `COMPILER_RT_BUILTINS_HIDE_SYMBOLS` CMake option to `OFF`, to ensure that we can link against those symbols in the general case. Note that these changes are simpler than previous efforts towards enabling `compiler-rt` builtins (e.g. numba#979) - this is because we now build as part of the whole `llvm-project` tree, which simplifies things and removes issues that had to be worked around when building it separately.
As part of #976 discussion, split the
llvmdevbuild into a separate PR for easier testing.Validated on Ubuntu, it builds
llvmwithcompiler-rtproperly.